Welcome @Skaronator!

It looks like this is your first PR to kubernetes-sigs/kustomize 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/kustomize has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

Hi @Skaronator. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

@koba1t Could you please take a look on this and do /ok-to-test command? Most of the CI Jobs already run anyway but tide and kustomize-presubmit-master are stuck - not sure why.

hi @ncapps @varshaprasad96 @koba1t this PR addresses a bugfix for #5566 , which is a highly upvoted issue at the moment. It’s been open for a while, so could we please review and prioritize it? Thanks!

/ok-to-test

/assign

@Skaronator

Thanks for your help that difficult issue!
I think this PR almost good!

So, I want to verify whether this feature works when a kustomization.yaml containing helmCharts is referenced via resources from another kustomizationFile. Please add test cases for this purpose.

Example

## ./kustomization.yaml
resources:
- dir1
namespace: ns-01

## ./dir1/kustomization.yaml
helmChart:
..... 

And, Please also add tests for cases where the namespace transformer and helmCharts.namespace are configured with different namespaces.

Example

## ./kustomization.yaml
namespace: resources-namespace
helmCharts:
  - name: service
    namespace: ns-configured-via-helm
    releaseName: service
    valuesFile: values.yaml

Additionally, having tests for cases where the same namespace is configured for both namespace transformer and helmCharts.namespace would help ensure reliable regression prevention.

Example

## ./kustomization.yaml
namespace: actual-namespace
helmCharts:
  - name: service
    namespace: actual-namespace
    releaseName: service
    valuesFile: values.yaml

This PR has multiple commits, and the default merge method is: merge.
You can request commits to be squashed using the label: tide/merge-method-squash

@koba1t Thanks for the review and suggestion for the additional test case.

During implementation, I discovered an underlying issue where Kustomize doesn't properly propagate the namespace field to sub-kustomization files when they're included via resources. This issue likely went unnoticed previously because
the top-level namespace transformer would apply namespaces to all resources afterward. However, since this PR modifies how the namespace transformer works (specifically skipping Helm-generated resources), this propagation gap became
problematic.

I've fixed this by ensuring that the parent kustomization's namespace is always propagated to child kustomizations when they don't already have a namespace defined. This ensures Helm receives the correct namespace during chart
rendering.

I've added comprehensive test cases for this specific use case, and the existing TestHelmChartProdVsDev test already provides extensive coverage by testing multiple top-level namespaces in overlay scenarios.

Hi @Skaronator
This PR is looks like good for me!
Thanks for your contribution.

/lgtm
/approve

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: koba1t, Skaronator

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Thanks!

For awareness: We're seeing substantial performance degradation in some of our overnight runs against master, and this appears to be the only commit that arrived since our previous run.

 === RUN   Test_kustomize/kust-issue-2869/kustomize/branch-master
    kustomize_test.go:296: Runtime variation (20.82x): branch-master ran in 22736ms; release-v5.1.1 ran in 1092ms.

This test runs what's described in #2869.

We have a significantly more complex test that has been running in around 65 to 70 seconds; as of today that test hits our run timeout of an hour.

I hope to have more time this weekend to provide more details.

Edited to add: Yes, the performance change is due to this commit.

=== RUN   Test_kustomize/kust-issue-2869/kustomize/branch-1c0f1bf
    kustomize_test.go:296: Runtime variation (18.79x): branch-1c0f1bf ran in 11557ms; branch-11f9435 ran in 615ms.

Regarding the faster run times here, the environment for this run was different than the one further above.

I profiled the test run.

CPU comparisons:

$ go tool pprof -top ./cpu-11f9435b5.prof | head -12
File: commands.test
Build ID: 311f46b11dd54fcdbdd9b4b680091961c677df0f
Type: cpu
Time: 2025-08-22 18:19:24 UTC
Duration: 607.15ms, Total samples = 470ms (77.41%)
Showing nodes accounting for 470ms, 100% of 470ms total
      flat  flat%   sum%        cum   cum%
      50ms 10.64% 10.64%       50ms 10.64%  runtime.duffcopy
      20ms  4.26% 14.89%       20ms  4.26%  internal/stringslite.IndexByte (inline)
      20ms  4.26% 19.15%       20ms  4.26%  runtime.duffzero
      20ms  4.26% 23.40%       40ms  8.51%  runtime.mallocgcSmallScanNoHeader
      20ms  4.26% 27.66%       20ms  4.26%  runtime.memequal
$ go tool pprof -top ./cpu-1c0f1bf5a.prof | head -12
File: commands.test
Build ID: 8e9580dcfb29ca38f4410c374692d5b7d313f64d
Type: cpu
Time: 2025-08-22 18:14:08 UTC
Duration: 10.16s, Total samples = 10.21s (100.47%)
Showing nodes accounting for 7.60s, 74.44% of 10.21s total
Dropped 388 nodes (cum <= 0.05s)
      flat  flat%   sum%        cum   cum%
     1.11s 10.87% 10.87%      1.11s 10.87%  runtime.memclrNoHeapPointers
     0.40s  3.92% 14.79%      0.40s  3.92%  runtime.memmove
     0.37s  3.62% 18.41%      1.09s 10.68%  runtime.scanobject
     0.31s  3.04% 21.45%      0.86s  8.42%  runtime.mallocgcSmallScanNoHeader
$

Memory comparisons:

$ go tool pprof -top ./mem-11f9435b5.prof | head -12
File: commands.test
Build ID: 311f46b11dd54fcdbdd9b4b680091961c677df0f
Type: alloc_space
Time: 2025-08-22 18:19:25 UTC
Showing nodes accounting for 195.86MB, 91.60% of 213.82MB total
Dropped 107 nodes (cum <= 1.07MB)
      flat  flat%   sum%        cum   cum%
      59MB 27.60% 27.60%       59MB 27.60%  sigs.k8s.io/kustomize/kyaml/yaml.NewRNode (inline)
   23.13MB 10.82% 38.41%    79.63MB 37.24%  sigs.k8s.io/kustomize/kyaml/yaml.(*RNode).Elements
   20.62MB  9.64% 48.05%    20.62MB  9.64%  go.yaml.in/yaml/v2.yaml_insert_token
   12.61MB  5.90% 53.95%    12.61MB  5.90%  go.yaml.in/yaml/v3.yaml_emitter_emit
   11.50MB  5.38% 59.33%    11.50MB  5.38%  sigs.k8s.io/kustomize/kyaml/yaml.CopyYNode
$ go tool pprof -top ./mem-1c0f1bf5a.prof | head -12
File: commands.test
Build ID: 8e9580dcfb29ca38f4410c374692d5b7d313f64d
Type: alloc_space
Time: 2025-08-22 18:14:18 UTC
Showing nodes accounting for 10934.93MB, 97.94% of 11165.23MB total
Dropped 224 nodes (cum <= 55.83MB)
      flat  flat%   sum%        cum   cum%
 7706.53MB 69.02% 69.02%  7882.79MB 70.60%  go.yaml.in/yaml/v3.yaml_emitter_emit
  607.56MB  5.44% 74.46%   607.56MB  5.44%  go.yaml.in/yaml/v2.(*parser).node (inline)
  411.69MB  3.69% 78.15%   411.69MB  3.69%  sigs.k8s.io/yaml.convertToJSONableObject
  328.02MB  2.94% 81.09%   328.02MB  2.94%  bytes.growSlice
  272.57MB  2.44% 83.53%   272.57MB  2.44%  reflect.mapassign0
$

Hmm....
If the performance degradation is actually occurring, this PR would need to be reverted.

@ephesused
Could you add that performance tests to CI on this repo?
I recommend defining a new GitHub Actions job.

I'll take a look if we can improve the performance. My guess is that the Namespace Transformer get applied multiple times in a nested way which is not necessary.